jira VULN-163195
cve-bf CVE-2025-38653
commit-author wangzijie <wangzijie1@honor.com>
commit 2ce3d28

To avoid potential UAF issues during module removal races, we use
pde_set_flags() to save proc_ops flags in PDE itself before
proc_register(), and then use pde_has_proc_*() helpers instead of directly
dereferencing pde->proc_ops->*.

However, the pde_set_flags() call was missing when creating net related
proc files.  This omission caused incorrect behavior which FMODE_LSEEK was
being cleared inappropriately in proc_reg_open() for net proc files.  Lars
reported it in this link[1].

Fix this by ensuring pde_set_flags() is called when register proc entry,
and add NULL check for proc_ops in pde_set_flags().

[wangzijie1@honor.com: stash pde->proc_ops in a local const variable, per Christian]
  Link: https://lkml.kernel.org/r/20250821105806.1453833-1-wangzijie1@honor.com
Link: https://lkml.kernel.org/r/20250818123102.959595-1-wangzijie1@honor.com
Link: https://lore.kernel.org/all/20250815195616.64497967@chagall.paradoxon.rec/ [1]
Fixes: ff7ec8d ("proc: use the same treatment to check proc_lseek as ones for proc_read_iter et.al")
	Signed-off-by: wangzijie <wangzijie1@honor.com>
	Reported-by: Lars Wendler <polynomial-c@gmx.de>
	Tested-by: Stefano Brivio <sbrivio@redhat.com>
	Tested-by: Petr Vaněk <pv@excello.cz>
Tested by: Lars Wendler <polynomial-c@gmx.de>
	Cc: Alexei Starovoitov <ast@kernel.org>
	Cc: Alexey Dobriyan <adobriyan@gmail.com>
	Cc: Al Viro <viro@zeniv.linux.org.uk>
	Cc: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
	Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
	Cc: Jiri Slaby <jirislaby@kernel.org>
	Cc: Kirill A. Shutemov <k.shutemov@gmail.com>
	Cc: wangzijie <wangzijie1@honor.com>
	Cc: <stable@vger.kernel.org>
	Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 2ce3d28)
	Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>

jira VULN-163195
cve-bf CVE-2025-38653
commit-author wangzijie <wangzijie1@honor.com>
commit 0ce9398

Commit 2ce3d28 ("proc: fix missing pde_set_flags() for net proc
files") missed a key part in the definition of proc_dir_entry:

union {
	const struct proc_ops *proc_ops;
	const struct file_operations *proc_dir_ops;
};

So dereference of ->proc_ops assumes it is a proc_ops structure results in
type confusion and make NULL check for 'proc_ops' not work for proc dir.

Add !S_ISDIR(dp->mode) test before calling pde_set_flags() to fix it.

Link: https://lkml.kernel.org/r/20250904135715.3972782-1-wangzijie1@honor.com
Fixes: 2ce3d28 ("proc: fix missing pde_set_flags() for net proc files")
	Signed-off-by: wangzijie <wangzijie1@honor.com>
	Reported-by: Brad Spengler <spender@grsecurity.net>
Closes: https://lore.kernel.org/all/20250903065758.3678537-1-wangzijie1@honor.com/
	Cc: Alexey Dobriyan <adobriyan@gmail.com>
	Cc: Al Viro <viro@zeniv.linux.org.uk>
	Cc: Christian Brauner <brauner@kernel.org>
	Cc: Jiri Slaby <jirislaby@kernel.org>
	Cc: Stefano Brivio <sbrivio@redhat.com>
	Cc: <stable@vger.kernel.org>
	Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 0ce9398)
	Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>

jira VULN-161937
cve CVE-2025-39766
commit-author William Liu <will@willsroot.io>
commit 15de71d

The following setup can trigger a WARNING in htb_activate due to
the condition: !cl->leaf.q->q.qlen

tc qdisc del dev lo root
tc qdisc add dev lo root handle 1: htb default 1
tc class add dev lo parent 1: classid 1:1 \
       htb rate 64bit
tc qdisc add dev lo parent 1:1 handle f: \
       cake memlimit 1b
ping -I lo -f -c1 -s64 -W0.001 127.0.0.1

This is because the low memlimit leads to a low buffer_limit, which
causes packet dropping. However, cake_enqueue still returns
NET_XMIT_SUCCESS, causing htb_enqueue to call htb_activate with an
empty child qdisc. We should return NET_XMIT_CN when packets are
dropped from the same tin and flow.

I do not believe return value of NET_XMIT_CN is necessary for packet
drops in the case of ack filtering, as that is meant to optimize
performance, not to signal congestion.

Fixes: 046f6fd ("sched: Add Common Applications Kept Enhanced (cake) qdisc")
	Signed-off-by: William Liu <will@willsroot.io>
	Reviewed-by: Savino Dicanosa <savy@syst3mfailure.io>
	Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
	Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com>
Link: https://patch.msgid.link/20250819033601.579821-1-will@willsroot.io
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 15de71d)
	Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>

jira VULN-187235
cve CVE-2025-68325
commit-author Xiang Mei <xmei5@asu.edu>
commit 9fefc78

In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen
and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes
that the parent qdisc will enqueue the current packet. However, this
assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent
qdisc stops enqueuing current packet, leaving the tree qlen/backlog
accounting inconsistent. This mismatch can lead to a NULL dereference
(e.g., when the parent Qdisc is qfq_qdisc).

This patch computes the qlen/backlog delta in a more robust way by
observing the difference before and after the series of cake_drop()
calls, and then compensates the qdisc tree accounting if cake_enqueue()
returns NET_XMIT_CN.

To ensure correct compensation when ACK thinning is enabled, a new
variable is introduced to keep qlen unchanged.

Fixes: 15de71d ("net/sched: Make cake_enqueue return NET_XMIT_CN when past buffer_limit")
	Signed-off-by: Xiang Mei <xmei5@asu.edu>
	Reviewed-by: Toke Høiland-Jørgensen <toke@toke.dk>
Link: https://patch.msgid.link/20251128001415.377823-1-xmei5@asu.edu
	Signed-off-by: Paolo Abeni <pabeni@redhat.com>

(cherry picked from commit 9fefc78)
	Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>

jira VULN-171936
cve CVE-2025-68366
commit-author Zheng Qixing <zhengqixing@huawei.com>
commit 1649714

There is one use-after-free warning when running NBD_CMD_CONNECT and
NBD_CLEAR_SOCK:

nbd_genl_connect
  nbd_alloc_and_init_config // config_refs=1
  nbd_start_device // config_refs=2
  set NBD_RT_HAS_CONFIG_REF			open nbd // config_refs=3
  recv_work done // config_refs=2
						NBD_CLEAR_SOCK // config_refs=1
						close nbd // config_refs=0
  refcount_inc -> uaf

------------[ cut here ]------------
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290
 nbd_genl_connect+0x16d0/0x1ab0
 genl_family_rcv_msg_doit+0x1f3/0x310
 genl_rcv_msg+0x44a/0x790

The issue can be easily reproduced by adding a small delay before
refcount_inc(&nbd->config_refs) in nbd_genl_connect():

        mutex_unlock(&nbd->config_lock);
        if (!ret) {
                set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags);
+               printk("before sleep\n");
+               mdelay(5 * 1000);
+               printk("after sleep\n");
                refcount_inc(&nbd->config_refs);
                nbd_connect_reply(info, nbd->index);
        }

Fixes: e46c728 ("nbd: add a basic netlink interface")
	Signed-off-by: Zheng Qixing <zhengqixing@huawei.com>
	Reviewed-by: Yu Kuai <yukuai@fnnas.com>
	Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit 1649714)
	Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>

jira VULN-184502
cve CVE-2026-43163
commit-author Jack Wang <jinpu.wang@ionos.com>
commit 46ef85f

A General Protection Fault occurs in write_page() during array resize:
RIP: 0010:write_page+0x22b/0x3c0 [md_mod]

This is a use-after-free race between bitmap_daemon_work() and
__bitmap_resize(). The daemon iterates over `bitmap->storage.filemap`
without locking, while the resize path frees that storage via
md_bitmap_file_unmap(). `quiesce()` does not stop the md thread,
allowing concurrent access to freed pages.

Fix by holding `mddev->bitmap_info.mutex` during the bitmap update.

Link: https://lore.kernel.org/linux-raid/20260120102456.25169-1-jinpu.wang@ionos.com
Closes: https://lore.kernel.org/linux-raid/CAMGffE=Mbfp=7xD_hYxXk1PAaCZNSEAVeQGKGy7YF9f2S4=NEA@mail.gmail.com/T/#u
	Cc: stable@vger.kernel.org
Fixes: d60b479 ("md/bitmap: add bitmap_resize function to allow bitmap resizing.")
	Signed-off-by: Jack Wang <jinpu.wang@ionos.com>
	Signed-off-by: Yu Kuai <yukuai@fnnas.com>
(cherry picked from commit 46ef85f)
	Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>

…red blocks

jira VULN-178618
cve CVE-2026-23270
commit-author Victor Nogueira <victor@mojatatu.com>
commit 11cb63b

As Paolo said earlier [1]:

"Since the blamed commit below, classify can return TC_ACT_CONSUMED while
the current skb being held by the defragmentation engine. As reported by
GangMin Kim, if such packet is that may cause a UaF when the defrag engine
later on tries to tuch again such packet."

act_ct was never meant to be used in the egress path, however some users
are attaching it to egress today [2]. Attempting to reach a middle
ground, we noticed that, while most qdiscs are not handling
TC_ACT_CONSUMED, clsact/ingress qdiscs are. With that in mind, we
address the issue by only allowing act_ct to bind to clsact/ingress
qdiscs and shared blocks. That way it's still possible to attach act_ct to
egress (albeit only with clsact).

[1] https://lore.kernel.org/netdev/674b8cbfc385c6f37fb29a1de08d8fe5c2b0fbee.1771321118.git.pabeni@redhat.com/
[2] https://lore.kernel.org/netdev/cc6bfb4a-4a2b-42d8-b9ce-7ef6644fb22b@ovn.org/

	Reported-by: GangMin Kim <km.kim1503@gmail.com>
Fixes: 3f14b37 ("net/sched: act_ct: fix skb leak and crash on ooo frags")
CC: stable@vger.kernel.org
	Signed-off-by: Victor Nogueira <victor@mojatatu.com>
	Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
Link: https://patch.msgid.link/20260225134349.1287037-1-victor@mojatatu.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 11cb63b)
	Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>

jira VULN-179375
cve CVE-2026-23392
commit-author Pablo Neira Ayuso <pablo@netfilter.org>
commit d73f4b5

Call synchronize_rcu() after unregistering the hooks from error path,
since a hook that already refers to this flowtable can be already
registered, exposing this flowtable to packet path and nfnetlink_hook
control plane.

This error path is rare, it should only happen by reaching the maximum
number hooks or by failing to set up to hardware offload, just call
synchronize_rcu().

There is a check for already used device hooks by different flowtable
that could result in EEXIST at this late stage. The hook parser can be
updated to perform this check earlier to this error path really becomes
rarely exercised.

Uncovered by KASAN reported as use-after-free from nfnetlink_hook path
when dumping hooks.

Fixes: 3b49e2e ("netfilter: nf_tables: add flow table netlink frontend")
	Reported-by: Yiming Qian <yimingqian591@gmail.com>
	Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
	Signed-off-by: Florian Westphal <fw@strlen.de>
(cherry picked from commit d73f4b5)
	Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>

jira VULN-183739
cve CVE-2026-43038
commit-author Eric Dumazet <edumazet@google.com>
commit 86ab3e5

Sashiko AI-review observed:

  In ip6_err_gen_icmpv6_unreach(), the skb is an outer IPv4 ICMP error packet
  where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2
  and passed to icmp6_send(), it uses IP6CB(skb2).

  IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm. The cipso
  offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm
  at offset 18.

  If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao
  would be a non-zero offset. Inside icmp6_send(), mip6_addr_swap() is called
  and uses ipv6_find_tlv(skb, opt->dsthao, IPV6_TLV_HAO).

  This would scan the inner, attacker-controlled IPv6 packet starting at that
  offset, potentially returning a fake TLV without checking if the remaining
  packet length can hold the full 18-byte struct ipv6_destopt_hao.

  Could mip6_addr_swap() then perform a 16-byte swap that extends past the end
  of the packet data into skb_shared_info?

  Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and
  ip6ip6_err() to prevent this?

This patch implements the first suggestion.

I am not sure if ip6ip6_err() needs to be changed.
A separate patch would be better anyway.

Fixes: ca15a07 ("sit: generate icmpv6 error when receiving icmpv4 error")
	Reported-by: Ido Schimmel <idosch@nvidia.com>
Closes: https://sashiko.dev/#/patchset/20260326155138.2429480-1-edumazet%40google.com
	Signed-off-by: Eric Dumazet <edumazet@google.com>
	Cc: Oskar Kjos <oskar.kjos@hotmail.com>
	Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260326202608.2976021-1-edumazet@google.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 86ab3e5)
	Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>

jira VULN-183733
cve CVE-2026-43037
commit-author Eric Dumazet <edumazet@google.com>
commit 2edfa31

Oskar Kjos reported the following problem.

ip4ip6_err() calls icmp_send() on a cloned skb whose cb[] was written
by the IPv6 receive path as struct inet6_skb_parm. icmp_send() passes
IPCB(skb2) to __ip_options_echo(), which interprets that cb[] region
as struct inet_skb_parm (IPv4). The layouts differ: inet6_skb_parm.nhoff
at offset 14 overlaps inet_skb_parm.opt.rr, producing a non-zero rr
value. __ip_options_echo() then reads optlen from attacker-controlled
packet data at sptr[rr+1] and copies that many bytes into dopt->__data,
a fixed 40-byte stack buffer (IP_OPTIONS_DATA_FIXED_SIZE).

To fix this we clear skb2->cb[], as suggested by Oskar Kjos.

Also add minimal IPv4 header validation (version == 4, ihl >= 5).

Fixes: c4d3efa ("[IPV6] IP6TUNNEL: Add support to IPv4 over IPv6 tunnel.")
	Reported-by: Oskar Kjos <oskar.kjos@hotmail.com>
	Signed-off-by: Eric Dumazet <edumazet@google.com>
	Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260326155138.2429480-1-edumazet@google.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 2edfa31)
	Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>